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(54) Authentication between eervers 

(57) A user (10) accessing resources on the Internet 
is often required to change servers (40A,40B) whilst in 
the middle of what for the user Is a single task. For ex- 
ample, the user rr^ay have accessed a multi-homed da- 
tabase or may have browsed a catalog on one server 
(40A) and now needs to go to another (408) to make 
payment. As many Internet resources require user au- 
thentication, the process of changing servers frequently 
results in the user having to re-authenticate himself/her- 
self. To overcome this problem the present invention 



provides that a server (40A) wishing to direct a user ( 1 0) 
to another server (40B) does so by returning ([2]) a URI 
that has been signed by the first serve r by including a 
signature in the URt. The user (10) uses this signed URL 
to access ([3]) the second sen/er (408). The second 
server (408) can then use the signature contained in the 
URL toconfinn that the user (10) has come from the first 
server (40A) and therefore does not need to be re-au- 
thenticated. Information can also be included In the URI 
and the signature used at the second server (408) to 
check its integrity. 
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<Destlnatioii URL>?Uscr=<User l(l>&ServerId=<OriginateServerld>& 
Traiisaction=<Traiisactioiild>&SessIoii=^<S€SsionId>& 

SoiirceHost=<OnginateProtocol>://<OrigmateHostName>:<OriginatePort>& 
SourceUIU.=<OriginateURl>&ServerTime=<ServerTime(GMT^ 
AuthTime»<LastAuthendcationTime>&Cii5tom=<CastomField>& 
Hash=<HashType>&SignedUrl=<Signature> 
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Description 

Field of the Invention 

[0001] The present invention relates to authentication 
between servers visited by the same agent such as a 
browser or sen^er^ide program. 

Baclcqround ol the Invention 

[0002] The World Wide Web operating over the Inte- 
rnet and Its intranet equivalents use the HTTP protocol 
for communicating agents (browsers) with servers. Fig- 
ure 1 shows the basic request /response messaging 
mechanism. More particulary, a browser 10 communi- 
cates with a server 11 by sending HTTP Requests 12 
and receiving back HTTP Responses 1 3. A Request 1 2 
is made up of a Request Line, a Request Header a CR 
1^, and a message body (the tatter being optional). A 
Response is made up of a Status Line, a Response 
Header, a CR LP, and a message body (again optional). 
[0003] When the browser wants to access a particular 
page held on the server 11, it sends a Request 12 with 
the identity of the desired page being given in the Re- 
quest Line; the server will then return the requested 
page in the message body of a Response 13. Where 
the browser 10 wants to query a database that has a 
web interface, it will send a Request to the interface, 
identifying the interface in the request Line (this line may 
also hold the query data); again the sender wilt return the 
requested information in a Response 13. 
[0004] As shown in Figure 1 , the Request Line 14 of 
a Request 12 has three elements, namely a Request 
Method, a URI (Uniform Resource Identifier), and a Pro- 
tocol Version. The URI 15 is usually composed of an 
http.URL 16 that identifies the resource to be accessed, 
and, optionally, a query 1 7 which if present is separated 
from the http.URL by a *?". In the Figure 1 example, the 
components of the UR1 15 have the following values: 

http_URL = http://www.apatentserver.com/cgi-bin/ 
query 

query = country=us&owner=iohnsmithco 

[0005] In this example, the browser is making a re- 
quest to a patent datat>ase to return information on any 
patent matching the query parameters - in this case, two 
conditions have been set. namely that the patent is for 
the US ('country=us") and that the patent owner is called 
JohmSmithCo ("owner=johnsmithco"). The two condi- 
tions are separated by an in the query. 
[0006] Figure 2 illustrates an application of the "cook- 
ie" mechanism that is widely used across the Web. A 
'cookie'is a piece of infomnation sent by a Web server 
to a Web browser that the browser software is expected 
to save and to send back to the server whenever the 
browser makes additional requests to the server. Cook- 
ies contain information such as login or registration in- 



formation, online 'shopping cart" informatton, user pref- 
erences, and the like. When a sen/er receives a request 
from a browser that includes a cookie, the server is able 
to use the information stored in the cookie. In the Figure 

5 2 scenario, the server 1 1 uses cookies to avoid a user 
having to re-authenticate himself/herself each time the 
sender is visited. More particularly, the server runs an 
authentication process 20 including a check task 21 that 
checks each incoming Request [1] intended for a par- 

10 ticular resource 25 to see if the Request carries a cookie 
(in the Request header) that has been previously set by 
the sen/er 1 1 and is still valk). If this is the case, the Re- 
quest is allowed to proceed [5]; otherwise the request is 
routed to a sign-on task 22 that returns [2] a sign-on form 

IS to the user at browser 1 0. The user completes this form 
(generally, user ID and pasword) and sends it back [3] 
to the sign-on task 22 which checks the input data. It the 
data checks out, a set-cookie task 23 returns [4] a first 
page of the requested resource in a Response that in- 

20 eludes a 'set cookie" command with an associated ses- 
sion user-code. The cookie is stored by the browser 10 
and included in subsequent Requests [5] to the resource 
25; the check task 21 allows such requests through with- 
' out invoking the sign on program (the check task has 

2S access to the session user-codes assigned by the set- 
cookie task). 

[0007] Figure 3 illustrates the situation of a user ac- 
cessing a multi-homed resource that is split across two 
servers 1 1 A and 1 1 B (servers A and B). To minimise the 

30 inconvenience of sucha split, the HTTP redirection 
mechanism may be used by which if server A receives 
a request for a resource page that has been moved to 
sender B. it will cause the browser 10 to automaticaly go 
to server B. Server A acieves this by returning a Re- 

35 sponse that includesa redirection status code in the sta- 
tus line of the Response, and the target URI in a location 
fieki of the response header 
[0008] A difficulty arises, however, when access to the 
desired resource is protected by a user-authenticaton 

40 process, this process being run on both server A and 
sen/er B (as respective authenticatran processes 20 A 
and 20B). Whilst cookies can be used to automatically 
authenticate users across two or more servers, this 
mechanism only works if the sen/ers are in the same 

45 network domain. In the Figure 3 example, the sen/ers 
1 1 A and 1 1 B are in different domains so that the cookie 
mechanism cannot be used. As a result, when a user 
who has signed on at sen/er A in order to access part 
of a multi-homed resource, wants to access a part of 

so this resource that resides on sen/er B, the user must 
sign on again at sen/er B. 

[0009] It may also be noted that even if servers A and 
b were in the same domain, the use of a cookie as a 
mechanism for avoiding the need to re-autnticate a user 
ss switching between sen/ers, i far from ideal as users have 
the ability to turn of this feature of their browsers so Its 
presence cannot be assumed. 
[0010] It is an object of the present invention to pro- 
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vide a convenient autiientication median ism spanning 
two servers visited by the same agent. 

Summary of the Invention 

5 

[0011] According to the preseni invention, there is 
provided an authentication method between first and 
second servers visited by the same agent, wherein: 

- following access by the agent to the first server, the 
latter directs the agent to the second sen/er by re- 
turning to the agent a URI that points to the second 
server, the URI including a signature adapted to 
guarentee that at least the signature of the URI orig- 
inates from a server belonging to a qualified set of 
sen/ers that has at least said one sen/er as a mem- 
ber, 

- the agent uses the URI retumed by the first server 
to access the second server with a request includ- 

. ing that URI, and 

- on receiving the request including said URI with its 
signature, the second server uses the received sig- 
nature to check that at least the signature originates 
from within said qualified set of sen/ers. 

[001 2] In one embodiment, the first sen/er directs the 
agent to the second sen/er by a redirection control code 
returned with the URI of the second server, the agent 
responding to the redirection control code to automati- 
cally generate and send said request to the second sen/- 
er. In another embodiment, the first sen/er directs the 
agent to the second sen/er by returning a page for dis- 
play that includes a hyperlink which when activated 
causes the agent to generate said request. 
[001 3] The signature will generally be formed from da- 
ta consisting of one or more elements each either in- 
cluded in the URI or already known to the second sen/er. 
Advantageously, one element is a predetemrilned por- 
tion of the URI and the signature is adapted to guarentee 
the integrity of that predetermined portion and its origi- 
nation from within the qualified set of sen/ers; in this 
case, the second sen/er can use the received signature 
to check the integrity of the predetermined portion of the 
received URI and Its orlginatk>n from within the qualified 
set of sen/ers. 

[0014] In one embodiment the first and second serv- 
ers share a common secret which is not included in the 
URI but forms one element of the data used by the first 
server for generating the signature; the signature being 
generated at the first sen/er by a process involving 
processing the data with a one-way function; and the 
second server carrying out its signature-based checking 
by: 

(1) - carrying out the same process as used by the 
first sen/er when generating the signature, on data 
that consists of the same one or more elements as 
used in generating the signature, these one or more 



elements being available at the second sen/er ei- 
ther in the received URI or as already known, and 
(ii) - comparing the result obtained in step (i) with 
the received signature. 

[0015] In another embodiment, the first server holds 
the private key of a private-key/public key pair and sec- 
ond sen/er knows the public key of this pair; the signa- 
ture being generated by the first sen/er by a process in- 
volving processing said data with a one-way function, 
and encrypting the result with its private key; and the 
second sen/er carrying out its signature-based checking 
by: 

(i) - carrying out the same one-way function as 
used by the first sen/er in generating the signature, 
on data that consists of the same one or more ele- 
ments as used in generating the signature, these 
one or more elements being available at the second 
sen/er either in the received URI or as already 
known, 

(ii) - decrypting the received signature using the 
public key, and 

(ill) " comparing the decrypted signature obtained 
in step (Ii] with the result obtained in step (1). 

[0016] One applk:ation of the method is to provide a 
'single sign-on' capability to a multi-homed site where 
access to the individual sen/ers of the site (the first and 
second sen/ers) is restricted by respective user authen- 
tication processes. In this applk;ation, the user authen- 
tication process of the second sen/er is satisfied by a 
agent accessing the second sen/er by a request includ- 
ing said URI with its signature where the signature con- 
firms its origination at the first sender. 
[0017] Where the signature is generated using data 
forming a predetermined portion of the URI. the method 
can b eused in a number of applications all involving the 
authenticat»n of information passed from the first serv- 
er to the second in the signed URI. In these applications, 
the second sen/er only acts upon infonnatlon present in 
the predetermined portion of the received URI after 
checking that the received signature confinns the integ- 
rity of said predetermined portbn and Its origination at 
the first sen/er. The transferred information may com- 
prise identification information relating to the agent. 
[0018] The transferred information may additionally or 
alternatively comprise transactkinal information relating 
to a transaction being conducted by the agent, the trans- 
action involving a first part with the first sen/er and a 
second part with the second sen/er with the second part 
using the transactional information transferred from the 
first sen/er. 



[0019] Embodiments of the invention will now be de- 
scribed, by way of non-limiting example, with reference 
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to the accompanying diagrammatic drawings, in which: 

Figure 1 Is a diagram illustrating the exchange of 
HTTP requests and responses between a browser 
and sen/er ^ 
Figure 2 is a diagram Illustrating a user-authentica- 
tion process using cookies to facilitate subsequent 
accesses during the same session; 
Figure 3 is a diagram illustrating the access of a 
browser to a multi-homed site; io 
Figure 4 Is a diagram illustratingtheuseof asigned 
URL in accordance with the present invention; 
Figure 5 is a diagram showing a preferred format 
of the signed URL used in Figure 4; 
Figure 6 Is a diagram illustrating a first method of is 
forming a signed URL and subsequently using it to 
effect integrity and origination checks; and 
Figure 7 is a diagram illustrating a second method 
of forming a signed URL and subsequently using it 
to effect integrity and origination checks. 20 

Best Mode of Carrying Out the Invention 

[0020] Figure 4 illustrates the basics of the present 
invention and shows a user agent (browser] 10 which 2S 
can communicate using the HTTP protocol with first and 
second HTTP servers 40 A and 40B (referred to below 
as Surlserver A and Surlserver B where "Surl'stands for 
"Signed URL* for reasons which will become apparent 
below). For simpilcity it will be assumed that Surlservers 30 
A and B each only host one site. 
[0021] Assume that browser 10 has sent [1] a Re- 
quest to Surlserver B (that is, to a resource of the hosted 
site). For whatever reason (and illustrative reasons are 
given betaw), Surlserver A determines that the browser 55 
1 0 should be directed to Surlserver B to sen/k^e the Re* 
quest. Surlserver A therefore returns [2] a Response in- 
cluding the URI of a target resource on Surlsen/er B. 
This URI Includes, as normal, the http_url of the target 
resource and any query data contained in the original ^0 
Request that it may be appropriate to transfer However, 
in addition, the URI has further data appended in query 
format. The contents of this further data will depend on 
surrounding circumstances but will always include a sig- 
nature formed by processing a predetermined portion of ^ 
the URI. This predetermined portion may be all or part 
of the URI excluding the signature itself. Two ways of 
forming the signature will be described bebw with re- 
spect to Figures 6 and 7; what is important is that the 
signature is formed in a way enabling it to be used to so 
check the integrity of the aforesaid predetemnined por- 
tion of the URI and its origination from the Surlserver A 
(or. in certain cases, from a larger set of Surlservers that 
have some common quality of interest to the Surlsen/er 
B). 55 
[0022] The URI including the signature forms what is 
termed herein as a "signed URL^ Process 41 run by 
Surlsen/er A is responsible for forming the signed URL 



and including it in a Response returned to browser for 
directing the latter to Surlsen/er B. 
[0023] How the signed URL is included in the Re- 
sponse will depend on how the browser is to be directed 
to Surlserver B. If the redirection capability of the HTTP 
protocol is used, then the signed URL is included in the 
location fieki of the response header and the status line 
Includes the appropriate redirection status code. In this 
case, browser 10 on receiving the Response from Sur- 
lserver A will automatically send [3] a Request to Sur- 
lserver B using the signed URL from the Response as 
the URI in the request line of the Request. Alternatively, 
Surlsen/er A can include the signed URL in a hyperlink 
contained in a page returned to browser 10 in the mes- 
sage body of the Response. In this case, when a user 
activates the hyperlink, the browser sends [3] a Request 
to Surlsewer B, again with the signed URL as the URI 
in the request tine of the Request. 
[0024] On receiving such a request from the browser 
10, a process 42 run on Surlserver B extracts the sig- 
nature and uses it to check the origin and integrity of the 
aforesaid predetermined portion of the URI . The Sur- 
lserver B then returns [4] a Response to browser 10, the 
nature of this Response depending on the outcome of 
the check carried out by process 41 . 
[0025] This general "signed URL" mechanism can be 
put to use in a number of ways as will be exam pled be- 
low. However, before doing so, a preferred formal for a 
signed URL will be described with reference to Figure 
5. f^re particularly, as well as the http.url of the desti- 
natbn sen/er (Surlsen/er B In Figure 4), the signed URL 
of Figure 5 include s a query made up of a number of 
parameter name/value pairs the last one of which is the 
signature itself (SignedUrl= < Signature > ). The first 
nine name/value pairs contain data about the user/user 
agent that generated the initial Request, the server gen- 
erating the signed URL, and their interaction. A brief ex- 
planation of each of these first nine parameters is given 
below: 



User : 
Serverld : 



Transaction : 

Session : 

SourceHost : 

SourceURL : 
ServerTime : 

AuthTime : 
Hash: 



a string representing the user 
a string repesenting the sen/er ef- 
fecting re-direction (that is. Surlserv- 
er A in Figure 4) 

current transaction between user 

agent and server (SurlserverA) 

current session between user agent 

and server (Surlserver A) 

host name of server effecting re-di- 

rectbn (Surlsen/er A) 

the URI trigerring the re-direction 

GMT time at server effecting re-di- 

rectbn (SurlserverA) 

time of generatk)n of signed URL 

identifier of hash functk)n used in 

generating signature. 



[0026] Finally, the penultimate parameter name/value 
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pair (Custom= <CustomField>) is optional and contains 
any relevant query data received in the Request being 
re-directed. 

[0027] For the Figure 5 signed URL, the signature is 
formed by processing all elements other than the final 
nameA/alue pair. 

[0028] Two applications of the general mechanism il- 
lustrated in Figure 4 will now be described with refer- 
ence to the interactions [1] to [4] shown in that Figure. 

Single Sign-On (Basic) 

[0029] In Figure 4 Surlservers A and B host respective 
sites; assume now that both sites have restricted access 
provided by respective user authentication processes at 
the Surlservers A and B. However, the Surlserver B site 
is willing to accept anyone authenticated for the Sur- 
Isen/er A site without requiring them to undergo re-au- 
thentication. Consider a user who has already success- 
fully gone through the sign on process at Surlserver. 
Surlserver A thereafter uses a cookie to facilitate further 
accesses by the user for browsing the site. If now the 
user wants to go to the Surlsen/er B site (for example, 
to complete a transaction started on Surlserver A), the 
Surlsen^er A site gives the user the opportunity to do so 
by presenting the user with a page including a linic 'Go 
to resource B" which points to a page "go.to.serverB. 
html" on Surlserver A. Upon the user activating the link 
the foltowing actions occur: 

[1] - a Request is sent for "goJo^serverB.html" on 
SurtserverA; 

[2] • Surlsen/er A has been configured to redirect 
every request to "go_to_serverB.htmr to check 
process 42 on Surlserver B, this process being at 
http_url: 

http://www.SurlserverB.com/cgi.bin/checkB. 
To do this, process 41 of Surlsen/er A forms a 
signed URL in the Figure 5 format and returns a Re- 
sponse with the signed URL in the location field of 
the response header and a redirection status code 
set in the status line of the Response. 
[3] - Browser 10 on receiving the Response sends 
a Request to Surlserver B with the signed URL as 
the URI in the request line. Surlserver B is config- 
ured to submit every Request directed to cgi.btn/ 
checkB to the process 42. If this process indicates 
that the signed URL in the Request comes from Sur- 
Isen^er A then the Surlserver B site knows it can 
trust the user agent 10 (Surlserver A having already 
carried out user authentication). As a result, the us- 
er is not asked to sign on again in order to access 
the site hosted on Surlserver B. 
[4] - When the signed URL has been successfully 
checked. Surlserver B returns a Response to 
browser 10 using this response to set a cookie for 
sutisequent accesses by browser 1 0. 



Signed Information 

[0030] The site hosted on Surlserver B may not in fact 

care who is accessing it - instead, this site may care 
5 much more about receiving valid information from the 
site on Surlsen/er A, typically about a transaction involv- 
ing the user Again the general signed-URL mechanism 
of Figure 4 is well suited to giving the reassurance 
sought by the site on Surlsen/er B. Consider a scenario 
10 in which Surlserver A hosts the web site of a merchant 
featuring e-commerce for software products. This site 
has a catatog and on-line purchasing but the software 
supplier company does lk:ense management through its 
site on Surlserver B. Once the customer (user of brows- 
is er 10) has bought the software he/she wants, the cus- 
tomer needs to be sent to the supplier's site. Thus: 

[1 ] - Customer has just bought a software product 
at the merchant's site on Surlserver A and has re- 
20 ceived back a page with all the order data (for ex- 
ample, order number: B928QW8) and an Instruction 
to follow a hyperlink to retrieve the license number 
This hyperlink has URI : 

http://www.Surlsen/6rA.com/Ge1Jicense. 
2S html?Order = 89^W8 The customer activates 
this link to send a Request to Surlserver with the 
above URI in the request line. 
(21 - Surlserver A has been configured to redirect 
every request to "Get Jicense.hlml" to a process 42 
30 on Surlsen/er B at http.url: 

httpy/www. SurlserverB.com/cgi.bin/ 
Generate.License To do this, process 41 of Sur- 
lserver A forms a signed URL in the Figure 5 format 
with the order number from the Request query now 
55 placed in the CustomField. Surlserver A then re- 
turns a Response with the signed URL in the loca- 
tion field of the response header and a redirection 
status code set in the status line of the Response. 
[3] - Browser 10 on receiving the Response sends 
40 a Request to Surlsen/er B with the signed URL as 
the URI In the request line. Surlserver B is config- 
ured to submit every Request directed to cgi.bin/ 
Generate_Lk:ense to the process 42. This process 
involves checking that the contents of the signed 
4S URL against its signature to ensure the integrity of 
the data carried by signed URL and its origination 
at Surlserver A.. 

[4] - When the signed URL has been successfully 
checked. Surlsen/er B returns a Response to 
so browser 10 with an html page including the lk:ense 
number for the customer. 

[0031] In fact, the single sign-on process described 
above will generally also involve using signed informa- 
55 tion passed from Surlserver A to Surtsen/er B. Indeed, 
as described above, the single sign-on process dkl pass 
signed information because it used the Figure 5 signed- 
URL format which, as already described, includes mul- 
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tiple parameter name/value pairs. However, the use of 
this information was not referred to; in practice informa- 
tion such as AuthTime will be used by Surlserver B dur- 
ing a single sign-on check. In particular, AuthTime will 
be used to check whether the validity of the signed URL 
has time expired, that is. whether or not the last user 
authentication was too long ago to still be considered 
valid; the integrity of the AuthTime needs to be authen- 
ticated because it would be an easy matter for a user to 
change this parameter. 

[0032] A more sophisticated form of single sign-on 
may be implemented in whk:h Surlserver B does not au- 
tomatically accept a user because the user has been 
passed to it from Surlsen^er A but. instead, Surlserver 
B carries out its own user authentication based on user 
data passed to it from Surlserver A In a signed URL In 
this case, Surlserver is trusting the integrity of data 
passed to it by Surlserver B but is making its own judge- 
ments based on that data. 

Signature Generation 

[0033] Figure 6 illustrates a first method of signature 
generation and checking. In this method, the generation 
and checking processes (carried out by Surlservers A 
and B respectively in Figure 4) share a common secret 
K. Signature generation involves combining the http-url 
and query (data) parts 50 of the planned URI (excluding 
the signature) together with the common secret K and 
subjecting them to a one-way function such as a one- 
way hash function 52 (for example, MD5 or SHA1 ) to 
produce a signature S. This signature is added (54) to 
the rest of the URI and sent as the signed URL Check- 
ing the signed URL on receipt involves decomposing 

(55) the received signed URL into the received signature 
SS and the remainder 57 of the signed URL (which 
should correspond to part 50). This remainder is com- 
bined with the comnrK)n secret K and the result is then 
subject to the same one-way function 52 as used upon 
signature generation to produce a regenerated signa- 
ture SSS. The regenerated signature SSS is compared 

(56) with the received signature SS and rf they match, 
the signed URL is taken as coming from the entity known 
to have the common secret K (or from within a group of 
such entitles where multiple entitles have the same key); 
the integrity of the remainder 57 is also taken as proven. 
[0034] Figure 7 illustrates a second method of signa- 
ture generation and checking. In this method, the gen- 
erating entity (Surlsen/er A in Figure 4) holds the private 
key K^pnv ^ private/public key pair (for example, for 
the RSA encryption algorithm) whilst the checking entity 
(Surlsen/er B) knows the public key K/^p^b- Signature 
generatkDn involves combining the http-url and query 
(data) parts 50 of the planned URI (excluding the signa- 
ture) and subjecting them to a one-way function such as 
a one-way hash functbn 52 (for example, MD5 or 
SH A1 ). The result of this process is encrypted (60) using 
the private key Ky^^v produce a signature S that is 



then added (54) to the rest of the URI and sent as the 
signed URL. Checking the signed URL on receipt in- 
volves decomposing (55) the received signed URL into 
the received signature SS and the remainder 57 of the 

5 signed URL (which should correspond to part 50). This 
remainder is subject to the same one-way function 52 
as used upon signature generation and the result com- 
pared (66) with the received signature after the latter 
has been decrypted using the public key K^pub- If a 

10 match is achieved, the signed URL is taken as coming 
from the entity known to have the private key Ky^p^^ (or 
from within a group of such entities where multiple en- 
tities have the same key); the integrity of the remainder 
57 is also taken as proven. 

IS 

Variants 

[0035] It will be appreciated that many variants are 
possible to the above<lescribed embodiments of the 
present invention. 

[0036] For example, if the receiving Surlserver B is 
only interested in knowing whether the agent has been 
directed to it from Surlserver A, then all that is needed is 
for Surlserver B to be able to confirm that the signature 
of the received URI originates from Surlserve r A. Indeed 
this is what is happening in the "Single Sign-On (Basic) 
" process described above. This basic functionality can 
in fact be achieved even without there being a need for 
the data used to generate the signature being precisely 
known to both senders. More partk:ularly, the signature 
can be formed by simply having Surlserver A encrypt a 
data element with its private key (without prior applica- 
tion of a one-way hash function), Surlserver B then de- 
crypting the signature with its public key. All Surlserver 
8 needs to know at>out the data element used to form 
the signature Is some discernible characteristic that dis- 
tinguishes the decrypted data in some way. For exam- 
ple, If the data element is a time stamp then Surlserver 
B need only know this fact without having any idea of 
the time value concerned - this is because it remains 
improbable that anyone not knowing the private key 
could generate anything looking like a timestamp when 
decrypted by the public key of Surlserver A. 
[0037] In order to make it possible to protect against 
replay attacks, each signature formed (in whatever 
manner) by Surlserver A preferably includes a compo- 
nent that is different each time the signature is formed 
(though it will be understood that there will generally be 
a limited range of possible values of this component so 
that for practical embodiments using, for example, a 
timestamp or pseudo-random-binary-sequence as the 
varying component, there will be a theoretical chance of 
two signatures being identical). 
[0038] As already indk^ated. Surlserver B may not ac- 
tually be interested in knowing that the signed URL orig- 
inates from a partk:ular sender but, rather, that It comes 
from a server within a qualified set of Surlservers. This 
can be readily achieved by giving the same common se- 
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cret / private key to all servers of this set (depending on 
whether the Figure 6 or Figure 7 signature generation 
method is used). 

[0039] Furthermore, although the invention has been 
described above in relation to a user agent (browser 10) 
interacting with Surlservers, the invention is usable with 
other agents such as a server-side CGI program. 
[0040] Further security (and in particular, confidenti- 
ality) can be provided by using SSL for the exchanges 
between the user 10 and the Surlservers A and B. 



Claims 

1 . An authentication method between first and second 
servers visited by the same agent, wherein: 

- following access by the agent to the first sender, 
the latter directs the agent to the second server 
by returning to the agent a URI that points to 
the second server, the URI including a signa- 
ture adapted to guarentee that at least the sig- 
nature of the URI originates from a server be- 
longing to a qualified set of senders that has at 
least said one server as a member, 

- the agent uses the URI returned by the first 
server to access the second server with a re- 
quest including that URI, and 

- on receiving the request including said URI with 
its signature, the second sender uses the re- 
ceived signature to check that at least the sig- 
nature originates from within said qualified set 
of servers. 

2. A method according to claim 1, wherein the first 
server directs the agent to the second server by a 
redirection control code returned with the URI of the 
second sender the agent responding to the redirec- 
tion control code to automatk:ally generate and 
send said request to the second server. 

Z. A method according to claim 1 , wherein the first 
sender directs the agent to the second sender by re- 
turning a page for display that includes a hyperlink 
which when activated causes the agent to generate 

said request. 

4. A method according to claim 1 , wherein the signa- 
ture is fonmed from data consisting of one or more 
elements each either included in the URI or already 
known to the second sen/er. 

5. A method according to claim 1. wherein one said 
element of the data used for forming the signature 
is a predetermined portion of the URI, the signature 
being adapted to guarentee the integrity of that pre- 
determined portion and its origination from within 
said qualified set of servers; the second sen/er us- 
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ing the received signature to check the integrity of 
saki predetermined portion of the received URI and 
its origination from within said qualified set of send- 
ers. 

A method according to claim 4 or claim 5, wherein 
the first and second senders share a common secret 
which is not included In said URI but forms one said 
element of the data used by the first sen/er for gen- 
erating the signature; the signature being generat- 
ed at the first server by a process involving process- 
ing the data with a one-way function; and the sec- 
ond server carrying out its signature-based check- 
ing by: 

(i) - carrying out the same process as used by 
the first server when generating the signature, 
on data that consists of the same one or more 
elements as used In generating the signature, 
these one or more elements being available at 
the second sen/er either in the received URI or 
as already known, and 

(ii) - comparing the result obtained in step (i) 
with the received signature. 

A method according to claim 4 or claim 5, wherein 
the first sen/er holds the private key of a private- 
key/public key pair and second server knows the 
public key of this pair; said signature being gener- 
ated by the first server by a process involving 
processing satd data with a one-way f unctkin, and 
encrypting the result with said private key; and the 
second server carrying out its signature-based 
checking by: 

(i) - carrying out the same one-way function as 
used by the first sen/er in generating the signa- 
ture, on data that consists of the same one or 
more elements as used in generating the sig- 
nature, these one or more elements being 
available at the second sen/er either in the re- 
ceived URI or as already known, 

(ii) - decrypting the received signature using 
the public key, and 

(iii) - comparing the decrypted signature ob- 
tained in step (ii) with the result obtained in step 

(i). 

A method according to claim 1. wherein the first 
sen/er holds the private key of a private -key/pubib 
key pair and second server knows the publk; key of 
this pair; said signature being generated at the first 
sen/er by encrypting with said private key a data el- 
ement that is not included in uncrypted form in the 
URI but at least characteristics of which are known 
to the second sen/er; and the second sen/er carry- 
ing out its signature-based checking by: 
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(i) " decrypting the received signature using 
the public key, and 

(ii) - comparing the decrypted form of said data 
element obtained in step (i) with the what is 
known by the second server about this element. 

9. A method according to any one of claims 4 to 8, 
wherein the signature is formed from data that has 
a component that is different each time the signa- 
ture is generated. 

10. A method according to any one of the preceding 
claims, wherein access to the first and second send- 
ers Is restricted by respective user authenticatk>n 
processes, the user authentication process of the 
second server being satisfied by a agent accessing 
the second server by a said request including said 
UBl where the signature-based checking carried 
out by the second server using the signature con- 
taining in the URl confirms that at least said signa- 
ture originates at said first server. 

1 1 . A method according to claim 5 or any claim depend- 
ent thereon, in which the first server passes infor- 
mation to the second sen/er in said predetermined 
portk)n of the URl and the second sen/er only acts 
upon this informatksn as present In the predeter- 
mined portion of the received URl after checking 
that the received signature confirms the integrity of 
said predetermined portion and its origination at 
said first server. 

1 2. A method according to claim 1 1 . wherein access to 
the second server is restricted by a user authenti- 
cation process and said information includes iden- 
tification informatton relating to the agent which the 
authenticatk}n process uses, after its integrity has 
been checked, to determined if the agent is to be 
allowed access to the second server. 

13. A method according to claim 1 1 . wherein said infor- 
mation includes transactional information relating to 
a transaction being conducting by the agent, this 
transaction Involving a first part with said first server 
and a second part with said second sen/er with the 
second part using said transactional information in- 
cluded in said predetermined portion by the first 
server. 

1 4. A method according (o claim 5 or any claim depend- 
ent thereon, wherein said predetermined portion of 
the URl is the whole URl other than said signature. 

1 5. A method according to claim 5 or any claim depend- 
ent thereon, wherein said predetermined portion of 
the URl includes a timestamp. the second sen/er 
using the timestamp in checking whether the signif- 
icance of the received URl has time expired. 



16. A method according to any one of the preceding 
claims, wherein the agent communicates with the 
the first and second sen/ers using an encrypted 
messaging scheme. 
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